|
This article is an excerpt from Chapter 6 of the book Extreme Programming Refactored: The Case Against XP [1], by Matt Stephens and Doug Rosenberg. The book provides an entertaining look at some of the flaws behind Extreme Programming (XP), whilst suggesting some alternative strategies and practical techniques to achieve XP's agile goals in a more rigorous way. For this article we concentrate on pair programming - and in particular the book Pair Programming Illuminated [2] by Laurie Williams and Robert Kessler.
Pair Programming Illuminated (we refer to it as PPI for the rest of this article), not surprisingly given its title, pitches the case for pair programming. However, it also discusses quite openly some of the problems typically encountered by pair programming teams. In this article, we focus on some of those problems and examine how they may affect an XP project as a whole.
Problems with Pairing Different Categories of Programmer
PPI divides programmers into different categories and then discusses the effects of the various combinations thereof. The programmer categories are novice, average, expert, introvert, and extrovert. The pairing combinations discussed in PPI, with a chapter dedicated to each, are as follows:
* Expert-expert
* Expert-average
* Expert-novice
* Novice-novice
* Extrovert-extrovert
* Extrovert-introvert
* Introvert-introvert
Because pairs are meant to rotate frequently, these various combinations will resurface often in a team of mixed abilities. Thus, in small teams (which is likely, given an XP project), it would be difficult to keep "problem pairs" apart.
"Go Make Me a Cup of Tea" Syndrome
What happens if you pair up a newbie programmer with an expert? This is described in PPI as "expert-novice pairing." The intention of such a pairing would be to "get the easier job done well, while training a novice programmer." The challenge of such a pairing is primarily that the expert must take on a tutoring role and must maintain extreme patience throughout. If the expert coder slips, then the result is a "watch while I type" session (sometimes called "go make me a cup of tea while I finish this program" syndrome [1]), in which the novice remains passive throughout and the expert is effectively solo-coding. Despite this, there are distinct advantages to expert-novice pairing. In fact, it's probably the one pairing combination that's worth mandating, as long as the novice is willing and able to learn and the expert is prepared to give up a portion of her day to teach rather than code in full-flow. This combination is certainly better than novice-novice pairing, which even XP evangelist Ron Jeffries thinks is a bad idea [2].
Laurel and Hardy Take Up Pair Programming
The intent of a novice-novice pairing combination is described in PPI as follows:
"To produce production code in a relatively noncomplex area of the project, giving valuable experience to both programmers in the process." [2]
If you're considering such a pairing, it's important to ask yourself which part of your project is unimportant enough that you can afford to unleash two complete novices, unsupervised, on it. "Unsupervised" is actually the key. Two novices, unsupervised, would likely produce code that isn't exactly production quality. Luckily, PPI has the answer:
"There must be a coach, instructor, or mentor available to answer questions and also to help guide the pair. . . .We feel very strongly about the need for a coach. If you are unwilling to assign the mentoring task to some expert, then you need to understand the limitations of the asset being produced by the pair." [2] In XP, this responsibility would fall into the lap of the person (or people) performing the coach role.
|
